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Method for accessing services and the inspection thereof, 
making use of- a mobile terminal 

BACKGROUND 

5 The invention relates to a method for accessing services. 
In particular, the invention relates to the facilitation, 
of the purchase and activation of a service by means of a 
form of "'electronic ticket" and the inspection for legal 
use . 

10 A variety of methods and systems are generally known, 
that usually make use of access cards and bank cards, 
etc . 

THE INVENTION 

15 It is an aim of the invention to make use of standard 
wireless terminals, such as mobile telephones etc., as 
"tickets" for services such as bus or train journeys 
etc., and in particular for enabling checking for legal 
use thereof. 

20 The method according to the present invention comprises 
the following steps: 

a. a user registers, by means of a user terminal via a 
transaction network, with a transaction processor of a 
service provider in order to access a particular service; 

25 b. if certain conditions are met, the transaction 
processor registers transaction parameters for the 
specification of the user, of the service, and of the 
transaction status . 

Normally, the service to be accessed will have to be paid 
30 for, upon which the transaction processor registers a 

payment code as transaction parameter. The payment can be 
made in co-operation with, for example, a banking 
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processor. Prior to the actual accessing of the service, 
a code can be transmitted to the transaction processor, 
whereupon this processor registers an activation code as 
transaction parameter. This action is analogous to the 
5 "stamping" of a bus or train ticket at the beginning of 
the journey. Via the terminal, the user can always make 
contact with the transaction processor in order to verify 
the transaction parameters. 

In particular, the invention relates to the inspection of 
10 the passengers. A further elaboration of the invention 
provides for. a (human or mechanical) inspector that 
checks a user for legal accessing of a service, for 
example travelling on bus or train - by direct or 
indirect inspection of the transaction parameters - via 
15 the transaction network - in the transaction processor. 
There are a number of variants for the inspection 
process . 

A first option is that the inspector requests the user's 
user terminal identifier and transmits it via the 

20 inspector terminal to the transaction processor, which 
reads out the transaction parameters relevant for 
inspection, that are registered for that identifier, and 
transmits them back to the inspector terminal. 
Subsequently, the inspector can, on the basis of the 

25 transaction parameters, check whether the user is making 
legal use of the service. The transaction parameters 
comprise all information required for inspection, such as 
- for a bus or train journey - the journey details, the 
sort of "ticket", etc. In addition, but of crucial 

30 importance with a view to security, is the option that 
the transaction processor validates the relevant 
transaction parameters and, depending on the result of 



BNSDOCID: <WO 0248926A1_L> 



WQ 02/48926, 



3 



PCT/EP01/13729 



the validation process, transmits back a status code to 
the inspector terminal. 

A second variant is one in which not the inspector but 
the user transmits his user terminal identifier to the 
5 transaction processor, which reads out the transaction 
parameters relevant for inspection, that are registered 
for that identifier, and transmits them back to the 
inspector terminal. In this case, the inspection process 
proceeds via the terminal of the user (initiation) and of 

10 the inspector terminal (result) instead of only via the 
inspector, just as in the previous variant. In this 
variant as well, use is preferably made of a status code 
that is transmitted back - in this case to the inspector 
terminal - as an extra check code, which is generated 

15 after evaluation in the transaction processor. 

In a third variant the user transmits his user terminal 
identifier to the transaction processor, which reads out 
the transaction parameters relevant for inspection, " that 
= are registered for that identifier, and transmits them 

20 back to the user terminal. In this variant the inspection 
process proceeds entirely via the user terminal. In. this 
case as well, preferably a status code generated by the 
transaction processor is . additionally transmitted, as 
extra security. 

25 Preferably, the inspection process comprises the step 

that the user requests the inspector terminal identifier 
of the inspector and transmits this identifier via the 
user terminal to the transaction processor, which 
calculates a status code that is dependent on this 

30 inspector terminal identifier and transmits back this 
status code to the user terminal. This step rules out 
possible confusion regarding the identity of the 
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inspector, whereby improper use could be made of a status 
code transmitted for use by another inspector. 
As regards the status code, provision is preferably made, 
with a view to fraud prevention, to ensure that the 
5 status code generated by the transaction processor takes 
a value which varies with time and is compared by the 
inspector with a verification code that changes 
synchronously with the status code. Since the status code 
changes regularly, provisions must also be made to change 

10 the verification code in exactly the same manner. A first 
variant provides for the status code to be generated in 
the transaction processor and transferred to the user 
terminal, while the verification, code is generated 
locally, in the inspector terminal. This requires a local 

15 code generator operating synchronously and according to 
the same algorithms as the code generator that generates 
the status code in the transaction processor. A second 
variant provides for the status code to be generated in 
the transaction processor and transferred to the user 

20 terminal, while the verification code is also generated 
in the transaction processor and transferred to the 
inspector terminal . 

Provision is preferably made, with a view to fraud 
prevention, to ensure that the status code generated by 
25 the transaction processor has a value dependent on the 
transaction parameters . 

If the evaluation by the transaction processor is 
positive, i.e. if the user is making legal use of the 
service, a status code is generated that is identical to 
30 the (autonomously generated) verification code. In the 
case of a negative result, a different code will be 
generated, so that the inspector can see (different 
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status code and verification code) that the user is not 
entitled to use the service. In such a case, inspection 
of the accompanying transaction parameters will reveal 
the cause of the negative evaluation result. 
5 Preferably, if the status code, is transmitted to the 
inspector terminal, the inspector terminal will 
independently give an error indication (signal or text) 
if the status code and the verification code differ from 
each other. 

10 The invention will now be described in more detail by 
reference to a system for the implementation of the 
method according to the invention. 



15 IMPLEMENTATION 

Figure 1 shows an example of a system for the 
'-- implementation of the method according to the invention. 
" In the system in figure 1 a user (1) registers her user 
■ terminal (2) via a transaction network (3) with a 
20 transaction processor (4) of a transport company. This 
registration must take place prior to the actual use of 
the service (drawn in the figure) , in this case before 
boarding the transport means. If certain conditions are 
met, the transaction processor 4 registers transaction 
25 parameters for specification of the user terminal 2, of 
the service - the route, the time - and of the 
transaction status (OK/NOK) . 

Normally, the user 1 will pay for the journey (in 
advance) by means of a banking processor 5, upon which 
30 the transaction processor registers a payment code as 
transaction parameter. As is customary for traditional 
tickets, the user will "activate" her ticket prior to the 
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journey, in the case of conventional tickets by means of 
"stamping". In this case, the "stamping" it is done by 
means of transmitting an activation code to the 
transaction processor, upon which this processor 
5 registers the activation code as transaction parameter. 
Naturally, the user 1 can make contact with the 
transaction processor via her terminal 2 in order to 
verify the transaction parameters. 

During or prior to the journey, a human (or possibly 

10 mechanical) inspector 6 can check whether the user 1 is 
travelling legally by direct or indirect inspection of 
the transaction parameters relating to that journey and 

passe n g e r — i-n— th e— t-r-an s a et-i-on— p r- o ce s s o r—$ 

The inspector can request the passenger 1 for her user 

15 terminal identifier - for example the telephone number of 
her terminal 2 - and transmit it via his inspector 
terminal to the transaction processor. The transaction 
processor then reads out the transaction parameters 
relevant for inspection, that are registered with that 

20 terminal identifier and transmits them back to the 
inspector terminal. The inspector therefore keys in 
"0613367789", upon which the transaction processor 4 
(provided that "the ticket" has been paid for and 
activated) answers "0613367789 Return Groningen The 

25 Hague first class". (In practice, abbreviations will be 
used that can be interpreted by the inspector, for 
example "0613367789 GNOGV 1".) If desired, the inspector 
terminal can receive the passenger's user terminal ID 
(e.g. telephone number) via an infrared or Bluetooth 

30 link, so that he does not need to key in the user 

terminal ID. An alternative is for the user terminal ID 
to be represented as a barcode on the user terminal that 
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can be read out electronically by the inspector by means 
of a barcode scanner integrated in the inspector 
terminal. 

A (supplementary) option is for the inspector to receive 
5 a status code (OK/NOK) from the transaction processor 
that is dependent on the findings of the transaction 
processor. If for example the inspector 6 has notified 
the processor 4 at the beginning of the journey that he 
is operating on the train from Groningen to The Hague, 

10 the processor 4 can return "OK" as status code. The 

transaction processor can also be fed with train-running 
information from a train running-information processor 8. 

I-n— fc-h-i-s— way-?— the— transaction-- processor— ^knows-^_between 

which stations the train is at any moment, so that 

15 "tickets" for sections of the route (for example Zwolle - 
Amersfoort) can be evaluated by the transaction processor 
for validity on that section of the route, 
v Variants of the above are that the user transmits the 
identifier (e.g. telephone number) of his user terminal 

20 to the transaction processor 4, which reads out the 

transaction parameters relevant for inspection, that are 
registered for that identifier and transmits them back to 
the inspector terminal, possibly supplemented by a status 
code ("OK/NOK") . In this case, the user terminal 

25 transmits and the inspector terminal receives the 

response. Assuming that the inspector has registered 
himself with the transaction processor at the beginning 
of the journey, the response will be returned to the 
correct inspector, providing that the user has a valid 

30 registration for the relevant route. Optionally, the user 
terminal can additionally send the identifier of the 
inspector terminal - that will then have to be requested 
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from the inspector or received via IR or Bluetooth, so 
that the response is always returned to the correct 
inspector. 

A second variant is that the user transmits his user 
terminal identifier to the transaction processor, that 
reads out the relevant transaction parameters and 
transmits them back to the user terminal. Here as well, a 
supplementary status code can be transmitted as a 
function of the evaluation of the parameters by the 
processor 4. In this case, the passenger 1 sends her 
identifier and also receives the response, which - via 
the display of the terminal 2 - is shown to the inspector 
6. Here as we ITT" tteSJSBxtttf i-er-of-the-i-nspeet-o-r-t-e-r-m-i-nal 
can be requested - via IR, Bluetooth or verbally - and 
transmitted to the transaction processor 4. 
in particular, if (a part of) the inspection process 
proceeds via the user terminal, it is desirable to 
provide extra security. In order to prevent - clever - 
users from "implanting" in their terminal an "OK" status 
code that is generated locally in their terminal 2 
instead of in the transaction processor 4, a status code 
is preferably taken with a value that varies with time. 
This is compared by the inspector with a verification 
code that changes in the same way and synchronously with 
the status code. The status code - which varies according 
to a specific algorithm - is generated in the transaction 
processor and transferred to the user terminal, while the 
verification code is generated locally in the inspector 
terminal. Accordingly, the inspector terminal comprises a 
processor that independently generates a verification 
code according to exactly the same algorithm as that by 
which the status code is generated in the transaction 



BNSDOCID: <WO 0248926A1 J_> 



WO 02/48926 PCT/EPO 1/1 3729 

9 

processor. This means that local creation of a status 
code in a user terminal with the aim of committing fraud 
no longer serves any purpose. Instead of locally 
generating the verification code in the inspector 
5 terminal, the verification code can also be generated 

centrally in the transaction processor and transmitted to 
the inspector terminal. This simplifies synchronisation 
of the status code and the- verification code. As an 
example of the above, assume that at a given time the 

10 inspector has the verification code "100988", which means 
that - if the passenger data are in order - the 
verification code will also have the value " 100988" . Some 

time later, how ever, the verification code " jumps" 

(autonomously or controlled from the transaction 

15 . processor) to a subsequent value, for example "766099". 
. If, on inspection, the passenger data are found to be in 
order, the transaction processor will generate "766099" 
as status code. If the passenger data are not in order, 
... the transaction processor will generate, for example, 

20 status code "000000" as ("NOK") or a code with an 

intrinsic meaning relating to the deficiency of the 
ticket, for example "000001" for "ticket not activated", 
"000002" for "ticket invalid on this route", etc. 
Although the above example is of a train journey, this 

25 can also be a journey by bus or any other means of 
transport. Nor is the invention limited to travel 
services, but can be applied to all possible services. 
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CLAIMS 

1. Method for accessing services, characterised by the 
following steps: 

a. a user (1) registers, by means of a user terminal (2) 
5 via a transaction network (3), with a transaction 

processor (4) of a service provider in order to access a 
particular service; 

b. if certain conditions are met, the transaction 
processor registers transaction parameters for the 

10 specification of the user, of the service and of the 
transaction status. 

2. Method according to claim 1, characterised in that the 
user pays for the service to-be acwssed— upon-which-t-he— 

transaction processor registers a payment code as 
15 transaction parameter. 

3. Method according to claim 1, characterised in that the 
user, prior to the actual accessing of the service, 
transmits a code to the transaction processor, upon which 
this processor registers an activation code as 

20 transaction parameter. 

4. Method according to claim 1, characterised in that the 
user can make contact via a terminal with the transaction 
processor in order to verify the transaction parameters. 

5. Method according to claim 1, characterised in that a 
25 human or mechanical inspector (6) checks a user for legal 

accessing of a service by direct or indirect inspection 
of the transaction parameters in the transaction 
processor. 

6. Method according to claim 5, characterised in that the 
30 inspector requests the user's user terminal identifier 

and transmits it via an inspector terminal (7) to the 
transaction processor, which reads out the transaction 
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parameters relevant for inspection, that are registered 
for that identifier, and transmits them back to the 
inspector terminal. 

7. Method according to claim 5 or 6, characterised in 
5 that the inspector requests the user's user terminal 

identifier and transmits it via an inspector terminal (7) 
to the transaction processor, which reads out the 
transaction parameters relevant for inspection, that are 
registered for that identifier, and as a function thereof 
10 transmits a status code back to the inspector terminal. 

8. Method according to claim 5, characterised in that the 
user transmits his user terminal identifier to the 

transaction— processor-, — which~r-eads_out_the_Jtraxisaction 

parameters relevant for inspection, that are registered 

15 for that identifier, and transmits them back to the 
inspector terminal. 

9. Method according to claim 5 or 8, characterised in 
that the user transmits his user terminal identifier to 
the transaction processor, which reads out the 

20 transaction parameters relevant for inspection, that are 
registered for that identifier, and as a function thereof 
transmits a status code back to the inspector terminal. 

10. Method according to claim 5, characterised in that 
the user transmits his user terminal identifier to the 

25 transaction processor, which reads out the transaction 
parameters relevant for inspection, that are registered 
for that identifier, and transmits them back to the user 
terminal . 

11. Method according to claim 5 or 10, characterised in 
30 that the user transmits his user terminal identifier to 

the transaction processor, which reads out the 
transaction parameters relevant for inspection, that are 
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registered for that identifier, and as a function thereof 
transmits a status code back to the user terminal. 

12. Method according to claim 11, characterised in that 
the user. requests the inspector terminal identifier of 
the inspector and transmits this identifier via the user 
terminal to the transaction processor, which transmits 
back to the user terminal a status code that is dependent 
on the inspector terminal identifier. 

13. Method according to claim 7, 9, 11 or 12 
characterised in that the status code generated by the 
transaction processor has a value which varies with time 
and is compared by the inspector with a verification code 

-Ch^tT^Kang-e-s— ^synchronous-l-y-w-i-t-h-t-he-sfea-tus-code-. 



15 



20 



25 



14. Method according to claim 11 or 12, characterised in 
that the status code is generated in the transaction 
processor and transferred to the user terminal, while the 
verification code is generated in the inspector terminal. 

15. Method according to claim 11 or 12, characterised in 
that the status code is generated in the transaction 
processor and transferred to the user terminal, while the 
verification code is also generated in the transaction 
processor and transferred to the inspector terminal. 

16. Method according to claim 7, 9, 11 or 12, 
characterised in that the status code generated by the 
transaction processor is dependent on the transaction 
parameters and is compared by the inspector with a 
verification code generated in the inspector terminal 
that is also dependent on the transaction parameters. 
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